![]() |
|||
![]()
|
![]() |
![]() Click Here! |
![]() |
Forward Explicit Congestion Notification (FECN) Forward explicit congestion notification (FECN) is end-to-end congestion control in which most of the computational complexity resides in the end system. To convey congestion information in the forward direction, the feedback mechanism uses explicit forward congestion indication (EFCI), which is carried in the payload type indicator field of an ATM cell. A source sends EFCI = 0 for every data cell transmitted. If the queue length of a switch exceeds a certain threshold, the switch is considered congested. When a switch becomes congested, it marks EFCI = 1 in all cells on each VC in the forward direction to indicate the congestion. Upon receiving a data cell with EFCI = 1, the destination generates and returns an RM cell to inform the source of the congestion status. The source reduces its cell rate when it receives the RM cell from the destination. The data and control traffic of FECN in a congested network with output buffer switches are illustrated in Exhibit 4-7-7.
Switch 2 has a queue experiencing congestion, and it marks the EFCI state of all cells on VC1 to indicate the congestion status. Destination 1 returns an RM cell to notify source 1 of the congestion. Upon receiving the RM cell, source 1 starts to reduce its cell rate. As in the case of the absence of the RM cell within a predetermined time period, the source will increase its cell rate until it reaches the peak cell rate. A time interval, the RM interval (RMI), is defined at the destination, and only one RM cell is allowed to be sent in an RMI. The source is also provided with an interval timer known as the update interval (UI). This scheme uses a negative polarity feedback and assumes an interval-based approach. This may result in overall network congestion collapse if the congestion notification cells returning to the source in the backward traffic experience extreme congestion because every source will attempt to reach the peak cell rate and overload the queue when the timer expires without receiving an RM cell from the destination. Backward Explicit Congestion Notification (BECN) Backward explicit congestion notification (BECN) returns the congestion notification directly from the point of congestion to the source. In this scheme, a source sends EFCI = 0 for every data cell transmitted. When a switch becomes congested, it marks EFCI = 1, and returns the BECN RM cell to inform the congestion to the source. The source reduces its cell rate on the receipt of the RM cell. If no BECN RM cell is received within a predetermined time period, the cell rate will increase until it reaches the peak. This scheme also uses a negative polarity feedback and assumes an interval-based approach as in FECN. Therefore, the scheme still has the overall network congestion collapse problem. An advantage of BECN is the faster response to congestion than that of FECN. In addition, BECN is more robust against faulty or noncompliant end systems because the network itself generates the congestion notification. However, BECN requires more hardware in the switches, not only to generate the BECN RM cells, but also to filter the congestion information. This filtering process is necessary to prevent generation of excessive RM cells. Exhibit 4-7-8 illustrates the data and control traffic of BECN in a congested network, where congestion occurs on VC1 at switch 2.
Proportional Rate Control Algorithm (PRCA) The proportional rate control algorithm (PRCA) is intended to remedy the problem of network congestion collapse with two major modifications: the positive polarity feedback approach and the counter-based approach (i.e., no interval timers). In PRCA, the feedback mechanism uses the EFCI state of the data cells. A source marks the EFCI bit in all data cells except for the first of every N RM cells and continually decreases its cell rate for every data cell transmitted. The parameter N is predetermined and will affect the response time to congestion and backward link utilization. When a destination receives a data cell with EFCI = 0, it instantly sends an RM cell to the source. The destination takes no action when the EFCI bit is set by an intermediate switch because of the congestion. A source only increases its cell rate for a VC when it receives an RM cell from the destination. Otherwise, it will continually reduce its cell rate because no source can increase its cell rate unless it has an RM cell from the destination. The increments and decrements in the cell rate of each VC are proportional to the current cell rate, thus eliminating the need for timers and timer value selection in previous rate-based proposal. PRCA allows both FECN-like operation and BECN-like operation because a switch experiencing congestion can change the state of EFCI = 0 to EFCI =1 or remove the RM cells in the backward direction. The problem of network congestion collapse associated with the FECN and BECN schemes is solved in PRCA. Exhibit 4-7-9 illustrates the data and control traffic of PRCA in a congested network where VC1 is congested at switch 2. Certain problems, however, remain even in PRCA. For example, PRCA requires a considerable amount of buffers when there is a large number of active connections because the decreasing of aggregated input rate at the switch is too slow.
In an ACR beat down problem, a VC goes through more congested links and its data cells are marked more often than those of other VCs going through fewer congested links. Consequently, such a VC will have a lowered cell rate (ACR) than others. For example, if p is the probability of bit being set on one hop, then the probability of it being set for an n-hop VC is pn. Therefore, the undesirable effect of VC starvation is proportional to the number of congested links on which a VC transmits its cells. The ACR beat down problem causes extreme unfairness among VCs in PRCA.
|
![]() |
|
Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details. |